[Previous] [Next] [Index]
[Thread]
Re: GSS API (as a DLL)...
>
> Alec Peterson writes [...]
>
> This is one of the reasons why most (if not all) applications that deal with
> secure data (like /bin/login and /bin/su) should be statically linked.
>
Actually, this rapidly becomes a circular argument. Security is an
ideal candidate for plug-ins, since the level of security needed is
directly (inversely) related to convenience and performance. So it makes
sense to implement security as something that can be exchanged and
replaced depending on one's needs. The question is what protects the plug-in?
Static linking is an obvious choice but I don't think one should throw the
proverbial baby out with the bathwater. One obvious option is to avoid the
Windows DLL behavior of looking for a library along a series of paths.
Windows currently looks in the current application directory, the windows
directory, or any other indicated path. For those arguing that under Unix,
plug-in security is a system admin issue, I would like to point out that
90% of CERT security announcements I get deal with system admin-related
laxities. So you don't want to leave this as a local policy issue.
Unix shared libraries are implemented in a way that absolute paths are
somewhat required. So the only way to spoof them is through direct
replacement of the component, or through symbolic links.
Here's what I would argue is what would work: make sure plug-ins are
loaded from absolute paths. Make sure, at the point of loading, that the
DLL file is NOT writable (some Unixes that memory map files and use the file
for implementing statics and globals might object), and finally, calculate
a CRC (or an MD5 signature) of the file and compare it against a stored
read-only file of checksums. This should at least establish location
and content. Now there are ways of spoofing even these, but at least
the window has been considerably narrowed. This level of checking should
be implemented for every shareable library access upon initial loading. Once
loaded, it's fairly safe to assume you can continue on and invoke the
functions within...
This type of security checking is going to become required as we move more
towards component-based software. It is going to be essential to verify
that a component it the right one (either by versioning or by security)
to use since it is no longer "built-in".
Cheers,
R.
--
Ramin Firoozye'
rp&A Inc. - San Francisco, California
Internet: rpa@netcom.COM - CIS: 70751,252
--
References: